FIG. 10-19 are diagrams illustrating the behavior of a traditional cluster system 500.
The cluster system 500 illustrated in FIG. 10 includes a cluster 503, an Ether Switch 502, and a client 501. The client 501 is connected to the cluster 503 via the Ether Switch 502.
The cluster 503 includes a device 504 and a device 505 to form a cluster configuration. Hereinafter, the device 504 and the device 505 may sometimes referred to as a device #1 and a device #2, respectively. The client 501 is connected to the devices #1 and #2 via a Local Area Network (LAN), and the Ether Switch 502 is disposed on the LAN.
The Ether Switch 502 switches the connection counterpart to the client 501 between the devices #1 and #2. In detail, the Ether Switch 502 switches between the devices #1 and #2 to selectively connect either device to the client 501. For example, when one of the devices #1 and #2 goes down, the Ether Switch 502 switches the connection counterpart to the other.
In the example of FIG. 10, the client 501 has an IP address “192.168.0.128” and the devices #1 and #2 have IP addresses “192.168.0.1” and “192.168.0.2”, respectively.
In the state illustrated in FIG. 10, the client 501 is connected to the device #1 and processes jobs through the Transmission Control Protocol (TCP) communication.
Under this state, when the device #1 goes down, the IP address of the device #1 is added to the device #2 (see arrow P1) as illustrated in FIG. 11, and the client 501 is connected to the device #2. The job being executed in the device #1 is transferred to the device #2 and the client 501 performs TCP communication with the device #2 to continue the process.
At that time, the device #2 stores therein a record (TCP connection information) of connection related to the TCP communication established with the client 501 (see Arrow P2).
TCP uses a sequential number for management of communication data. The TCP connection information includes the sequential number (see Arrow P3). The sequential number is sometimes used by a job.
After the device #1 is restored, the job of the device #1, which job has been executed by device #2 on behalf of the device #1, is returned to the device #1. The client 501 is connected to the device #1 and performs the TCP communication with the device #1 to continue the process.
In this case, the TCP connection information used by the job that the device #2 has performed on behalf of the device #1 is left in the device #2 (see Arrow P4). This is because TCP connection information is management information inside the Operating System (OS) and is therefore not able to be modified by an external application program.
In the device #1, restarting the communication with the client 501 proceeds to the communication of “Sequential no. B”, as illustrated in FIG. 13 (see Arrow P5).
[Patent Literature 1] Japanese Laid-open Patent Publication No. 2002-344450
[Patent Literature 2] Japanese Laid-open Patent Publication No. 2006-215635
[Patent Literature 3] Japanese unexamined Patent Application Publication (Translation of PCT application) No. 2011-518486
In the state illustrated in FIG. 13, in cases where the device #1 goes down again, the device #2 takes over the job being executed in the device #1 as illustrated in FIG. 14.
In this event, the client 501 that is using the cluster 503 makes an access to the device #2, using the TCP connection information before the device #1 goes down. In this access, a TCP port number used for an access from the client 501 coincides with the TCP connection information left in the device #2.
Here, in cases where the sequential numbers of the client 501 and the device #2, which communicate with each other, mismatch, congestion of TCPACK (acknowledgement) occurs.
As described above, the TCP uses a sequential number for management of communication data. In cases where the sequential number is different from an expected value, the receiver transmits a response (ACK) to the sender to request transmission of data having the expected sequential number.
If the sender, which has received this ACK, is not able to prepare the requested data, the sender transmits the sequential number that the sender manages to the receiver for the acknowledgement (ACK). This means that the sender and the receiver reply to each other with respective expected sequential numbers.
In the example of FIGS. 14 and 15, since the communication between the client 501 and the device #1 proceeds to “Sequential no. B”, the client 501 sends the sequential number “B+1” successive to “B” to the device #2.
In contrast to the above, since the TCP connection information (“Sequential no. A”) used in the last communication with the client 501 is left in the device #2 (see Arrow P6 in FIG. 14), the device #2 expects the sequential number “A+1” next to “A”.
As the above, the expected sequential number of the client 501 mismatches that of the device #2. The device #2 replies to the client 501 with ACK requesting transmission of data having a sequential no. “A+1”. Unfortunately, the client 501, which receives the ACK, is unable to prepare the requested data and replies with ACK notifying that the next sequential no. in the client 501 is “B+1”.
Repeating (congestion) of such a reply with ACK continues until communication time-out (more than seconds), which is one of the cause of delay in switching in the cluster.
The TCP connection information 60 is managed by the kernel of an OS and is not easily deleted.
This delay is ordinary in a Network File System (NFS) server having a cluster configuration.
Congestion caused from repetitious ACK reply occurs also in cluster switching caused from Link down.
The cluster system illustrated in FIG. 15 is in a state where the client 501 is communicating with the device #1 and the communication has proceeded to “Sequential no. X” (see Arrow P7). The device #1 is further connected to another client via a non-illustrated different LAN and processes a job from the other client.
As illustrated in FIG. 16, the LAN connecting the device #1 to the Ether Switch 502 is assumed to link down (see Arrow P8). However, since no failure occurs in the other LAN (not illustrated) that connects the device #1 to the other client (not illustrated), the device #1 continues to function as a device that processes a job from the other client.
As illustrated in FIG. 17, in the cluster 503, the IP address of the LAN that has come to be disable the device #1 is appended to the device #2 (see Arrow P9), so that the job being carried out by the device #1 is taken over by the device #2. This proceeds the communication of the device #2 with the client 501 to “Sequential no. Y” (see Arrow P10).
After that, as illustrated in FIG. 18, when the LAN that connects the device #1 to the client 501 links up (see Arrow P11), the IP address of the device #1, which address is set in the device #2, is returned to the device #1 (see Arrow P12) and the job that has been taken over by the device #2 is resumed.
At that time, the TCP connection information used by the job that the device #2 has performed on behalf of the device #1 is left in the device #2 (see Arrow P13).
Since the client 501 using the cluster 503 proceeds the communication with the device #2 to “Sequential no. Y”, the client 501 sends an ACK attaching thereto the sequential number “Y+1” successive to “Y” to the device #1.
In contrast to the above, since the TCP connection information (“Sequential no. X”) used for the last communication with the client 501 is left in the device #1 (see Arrow P14) as illustrated in FIG. 19, the device #1 expects the sequential number “X+1” successive to “X”.
This causes mismatch in sequential number between the client 501 and the device #2, which TCP communicate with each other, and consequently congestion of TCP ACK occurs.
As described above, such a traditional cluster system causes congestion TCPACK when the sequential number of the client 501 mismatches those of the devices #1 and #2 constituting the cluster 503 at resuming communication.